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Background of the Invention 

1. Field of the Invention 

The present invention relates to performing a process by linking a plurality of pages 
defined in a mark-up language that are executable by a browser, wherein the process 
implements operations via dynamically linked operational -objects. 

2. Description of the Related Art 

Mark-up languages, such as hypertext mark-up language (HTML), provide a useful 
environment for the establishment of sophisticated graphical displays and, as such, are very 
suitable for inviting input responses from users via a graphical user interface. In addition to 
displaying graphical entities, it is also possible to embed executable scripts within HTML pages 
that in turn may include controls for call ing dy namically linked objects^ 

A problem with embedding objects of this type within HTML pages is that active X 
controls are often relatively large and thereby significantly increase the operational time 
required for an HTML page to be loaded from storage or to be received via a network or an 
Internetwork connection. Although this may be acceptable in many environments, there are 
many other environments, particularly those of a commercial nature, where it is highly 
undesirable for the time taken for a page to be created to be any larger than necessary. 

A further problem exists in that controls are destroyed when a page as a whole is 
destroyed, usually to enable a new page to be created. 

A further problem exists with embedded controls in that the nature of the control itself 
is readily accessible when contained within an HTML page and under some environments this 
may be considered undesirable. 

A process defined by a plurality of linked HTML pages is illustrated in Figure A. In this 
example, three HTML pages Al, A2 and A3 are shown although the system could include 
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considerably more. These HTML pages may be read from local storage, received via a network 
or received via an online connection to an Internet or a dedicated link to a remote host 
computer. Each is capable of generating graphical information, illustrated by the left region of 
each page. In addition, each page may contain an embedded script, executable by a browser, 
5 illustrated by the right portion of each page. This script may include Active X controls or 
similar, such as control A4. During the execution of page Al, by browser A5, control A4 is 
executed, resulting in an instance of a library object being created, as illustrated by arrow A6. 
The instantiated object will perform a called function and will then return an event, illustrated 
by arrow A7. 



n 1 o Process flow is achieved by HTML pages, such as page A 1 , having links to other pages, 

^? such as A2, as illustrated by arrow A8. Under the environment shown in Figure A, it is possible 

-4 

O for page Al to call a function and then continue to execute instructions, or respond to user 

Q input, before event A7 is received. Part of this subsequent processing may involve the 

gi execution of link A8 under the control of the browser A5. Under these circumstances, browser 

^15 A5 will close object Al and instantiate HTML page A2. If the event A7 now returns, it has 

^ nowhere to return to and is thereby effectively lost. 

M« Browser control B5 provides functionality of a conventional browser but in an 

n 

□ embedded form. Consequently, a program is required in order to control the browser control 
and this is achieved by the establishment of a browser container A9. In addition to controlling 

20 browser control A5, container A9 is also tasked with ensuring that reliable operation of the 



browser control is maintained and, where necessary, reloading the browser control so as to 
restart the operation. In this way, the overall application is maintained and it is not necessary to 
rely upon the default crisis management provisions of the operating system, or on manual 
intervention from a user. 

25 The instantiation of an HTML page into system memory takes a longer period of time 

when an HTML page contains many Active X controls, such as control A4. It would therefore 
be desirable to initialize these strongly typed controls during an initialization procedure, prior to 



the loading and processing of the HTML page. However, a problem exists in that a returning 
event, such as event A7, must be returned to the originating page in order for the original calling 
process to be satisfied. 

Under the environment shown in Figure A, a systems developer may be under some 
5 pressure to reduce the number of Active X controls embedded within HTML pages in order to 
ensure that the time taken to load a page is not excessive. Furthermore, a developer may also be 
placed under further constraints so as to minimize the chance of an event being returned to an 
HTML page after that HTML page has been closed down and a new page has been established. 
-J* may also be desirable to reduce the amount of script contained on HTML pages so as to make 



10 it less accessible to third parties. 
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Brief Summary of the Invention 

According to an aspect of the present invention, there is provided data processing 
apparatus having processing means, memory means and display means. The processing means 
1 5 performs a process in response to program instructions read from the memory means via 

dynamically linked operational objects called by control objects, such that events are returned 
Li back to a calling control object. A plurality of pages are defined in a mark-up language that are 
~ selectively displayed and executed by a controlled browser. The controlled browser is controlled 

by a controlling container object and active control objects for calling said operational objects 
20 are contained within the container object. A single pass-through object is created and at least 
one of the pages includes a page embedded control object configured to call the pass-through 
object. ^Cb- initiating one of the page embedded objects calls the pass-through object and passes 
to the pass-through object output information detailing a desired call to a specific operational 
object. The pass-through object interprets output information received from a page embedded 
25 object to generate a call to a contained object that in turn calls the desired operational object. 
The pass-through object receives event data from a called operational object and returns input 
data to the initiating embedded object indicative of the returned event. 



In a preferred embodiment, any process configured to create a pass-through object will 
firstly ensure that such an object is not in existence and only create the object if it is not in 
existence thereby ensuring that only one pass-through object exists at any one time. 

Preferably, the call to a contained object is made via a specific decoding object within 
the container. 

In a preferred embodiment, the return events are returned to an initiating page via the 
pass-through object. The pass-through object may maintain a register of established pages and 
may also contain a buffer for buffering events to be returned to the pages that are no longer 
established within the process. Preferably, buffered events are returned to non-established 
pages after said pages have been re-established. 

Brief Description of the Several Views of the Drawings 

Figure A illustrates a process flow achieved by linked HTML pages of the prior art; 
Figure 1 illustrates an environment for the exploitation of the present invention; 
Figure 2 illustrates internal hardware structure of the environment illustrated in 
Figure 1 ; 

Figure 3 shows an example of a customer session performed within the environment 
shown in Figure 1 ; 

Figure 4 illustrates a software environment executable within the environment shown in 
Figure 1 to perform a procedure of the type shown in Figure 3; 

Figure 5 details operations performed by page embedded controls of the type identified 
in Figure 4; 

Figure 6 illustrates procedures performed by an encoder function identified in Figure 4; 

and 

Figure 7 illustrates a flow of information between an HTML page and an application 

object. 



Best Mode for Carrying Out the Invention 

An environment that exploits hypertext mark-up language (HTML) pages for the 
display of graphical information is identified in Figure 1. In this example, the pages are 
embedded within a cash dispenser, often referred to as an automatic teller machine (ATM). 
This represents an example of a wider class of devices for the remote servicing of customers 
that may be more generically referred to as self service terminals. However, the present 
invention is not limited to applications of this type and may be exploited in any environment 
where a process defined by a plurality of HTML (or other mark-up languages such as XML 
etc) are being used to define a process that in turn implements operations via dynamically 
linked operational objects. 

The self service terminal (SST) 101 shown in Figure 1 includes a graphical display 
102, such as a cathode ray tube (CRT) visual display unit, a liquid crystal display (LCD) unit 
or similar. The display 102 preferably conforms to SVGA standards and is capable of 
displaying basic text, animated text or full motion video. The visual display unit 102 often 
displays menus from which selections may be made via soft keys 103, of which four are 
positioned to the left of the visual display 102 with a similar collection of four being 
displaced to the right of the VDU 102. 

The terminal 101 includes keypad 104, primarily provided to allow customers to enter 
personal identification numbers and to specify any currency amounts that may not be available 
from displayed menu selections. A customer's transaction card is received within a card reader 
105, transaction slips, detailing the nature of a transaction or identifying balances etc are printed 
by means of a slip printer 106 and currency is dispensed via a cash dispenser 107. 

The internal structure of terminal 101 is shown schematically in Figure 2. The system 
operates under the control of a Pentium HI central processing unit 201 connection to one 
hundred and twenty-eight megabytes of system memory 202 via a communications bus 203. 
New program instructions are conveyed by a CD ROM 204 receivable within a CD ROM 
reader 205. During an installation process, program instructions are written to a resident hard 



disk drive 206. These instructions include HTML pages with linking scripts, other object 
programs loaded during initialization and a plurality of dynamically linkable objects contained 
within a library held on disk 206. Other mechanisms may be deployed for the installation of 
program instructions, such as a network connection, an Internet connection or a direct 
5 connection to a remote host computer. 

Graphical images are conveyed to visual display unit 102 via a graphics card 207. A 
conventional interface device 208 allows connections to a conventional mouse and keyboard, 
although these are not required for the remote embedded application of the system. A dedicated 
interface device 209 facilitates the reception of data from soft keys 103, the reception of data 
p 10 from card reader 105, the supply of information to slip printer 106, the control of cash dispenser 
107 and the reception of data from keypad 104. Communication with a remote host computer 
is achieved via a modem 210 connected to a telecommunications line to said host computer 
21 1, or via a dedicated communications link. 

Communication between the devices shown in Figure 2 is established under the 
1 5 operating system Windows NT. When power is applied to the system, Windows NT loads, 

followed by the loading of an application program in order to provide the embedded and remote 

P 

H= functionality. Objects are initialized within the system to the point where a steady state is 

p reached where the machine is effectively waiting for a new transaction to be initiated. A 

transaction is initiated by a card being inserted within card reader 105 which, if authorized, will 
20 then result in an interactive session being initiated. 

During the interactive session, graphical displays are presented to a user on VDU 102 
and the graphical information is generated from respective HTML pages. These HTML pages 
are linked such that it is possible to move from one page to another after particular conditions 
have been satisfied. In this way, it is possible to define an overall customer flow that may in 
25 turn establish flows involving dynamically linked objects for particular transactions. 

An example of a customer session is illustrated in Figure 3. At step 301 an HTML page 
supplies graphics to VDU 102 inviting a customer to insert a card. In response to a card being 
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inserted, the card is read at step 302, whereafter a new HTML page is called at step 303 in order 
to invite a customer to define a transaction type. At step 304, soft keys 103 are interrogated 
whereafter an appropriate new HTML page is called to display information relevant to the type 
of transaction defined by the operation of the keys at step 304. Thus, it can be appreciated that, 
at this point the flow could branch in many directions and the process shown in Figure 3 is 
merely a single example of this. 

In the example shown in Figure 3, a customer has elected to withdraw currency and at 
step 305 a customer is invited to define a transaction amount. Soft keys 103 are interrogated 
again at step 306 thereby instructing the terminal as to the quantity of currency required by the 
customer. 

At step 307 a slip is printed by means of slip printer 106 and at step 308 cash is 
dispensed by operation of cash dispenser 107. 

A new HTML page is generated at step 309 inviting the customer to remove dispensed 
cash and a question is then asked at step 301 to check that all is now clear, i.e. that the cash has 
been removed and therefore the session has been completed. If answered in the negative, 
further invitations are made to the customer to remove cash and eventually the question asked at 
step 310 will be answered in the affirmative, allowing control to be returned to step 301. 

The software environment in which the procedures identified in Figure 3 are effected 
are illustrated in Figure 4. The procedures will operate within the Windows NT operating 
system, thereby providing a communications manager 401 for in process and out process 
communications between objects. A dynamically linked library 402 is provided, having library 
objects with functions therein that have been grouped into three functional types, consisting of 
business services 403, channel applications 404 and channel services 405. 

The channel services functions 405 provide abstracted interfaces for devices within the 
terminal itself. They include what may be considered as device drivers for devices such as the 
card reader 105 and the cash dispenser 107 etc. Functions coming under the category of 
business services 403 are concerned with interactions of the host computer via modem 210 on 
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line 211. These include account services that identify the types of accounts held by customers 
and provide information relating to customer balances, consumer interfaces that provide 
information about particular customers such as their age and their financial status and card 
functions that consider aspects of processing details contained on cards and in particular 
customer acceptance in order to allow a session to be initiated. 

Channel applications provide the essential core to the operations provided by the 
terminal and are called dynamically when a session is taking place. These calls are instigated 
by linked HTML pages, such as pages 406, 407 and 408. In Figure 4, these three pages are 
shown simultaneously for illustrative purposes. In the actual implementation, these pages are 
created sequentially and are supported by a browser control 409. The browser control 409 is 
embedded within a container program 410, providing the functionality of container A9 
described with respect to Figure A. However, in Figure A, Active X controls were embedded 
within the HTML pages. In this embodiment, Active X controls 41 1, 412, 413, 414, 415, 416 
and 417 are embedded within the container program 410. 

Each HTML page 406 to 408 includes script to allow a first HTML page to be linked to 
a second HTML page. Thus, for example, HTML page 406 includes script 421 that, when 
appropriate conditions are met, will result in HTML page 406 being closed and HTML page 
407 being established. Similarly, script 422 in HTML page 407 will, under appropriate 
conditions, cause HTML page 407 to be closed down and HTML page 408 to be loaded. 

Each HTML page 406 to 408 includes an embedded control 423 that is effectively an 
agent configured to provide a means of communication to Active X controls contained within 
the container and as such, it may be referred to as a "container agent' \ 

In addition to having Active X controls 41 1 to 417, the container also includes a 
communication decoder 424 configured to effectively receive calls from page embedded 
controls 423 and decode this information so as to generate an appropriate function call to one of 
the embedded Active X controls 41 1 to 417. Thus, decoder 424 is an agent responsive to 
commands received from the HTML pages and as such may be referred to as a "page agent". 
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Communication between the container agents 423 and the page agent 424 is effected via 
an independent pass-through program 43 1 that is executed within the multitasking environment 
of the operating system. Thus, all of the functionality previously described may be considered 
as operating within its own individual main application program 432 and communication 
5 between these two separate processes is established through the communications manager 401 . 

Pass-through program 431 includes an event buffer 433, an encoder 434 and a page 
register 435. Page embedded controls (the container agents) make conventional calls to encoder 
434 of the pass-through program 43 L Encoder 434 encodes this information in order to make a 
method call to decoder 424 (the page agent) embedded within the container 410. Method calls 
1 0 are decoded by decoder 424 to generate conventional function calls to the Active X controls 
411 to 417. These in turn create events to be passed back to the calling Active X control. In 



□ turn, the controls pass the information back to the decoder 424 which now performs an 



encoding process to return the event information, in the form of a method call, back to the 
encoder 434, In terms of receiving this event information, the encoder 434 now effectively 



^ 1 5 provides a decoding process such that the event may be returned to the initiating page. 

H 1 Before encoder 434 returns event information, its page register 435 is interrogated. The 

page register 435 maintains a record of active pages. If the originating page is active, the 
p encoder returns the event to that page. Alternatively, if for some reason the page is no longer 

active, the event information is held within an event buffer 433. The event information remains 
20 in the event buffer 433 until the originating page becomes re-registered, as recorded by the page 
register 435, whereupon the event information may then be returned to that initiating page. 

To summarize, a process is defined by a plurality of HTML pages 406 to 408, called and 
executed by a browser control 409. Operations are implemented via dynamically linked 
operational objects 441. In the example shown in Figure 4, Active X control 417 calls object 
25 44 1 , that will in turn return an event back to the calling control object 4 1 7. 

The HTML pages are selectively displayed and executed by a controlled browser 409, 
that is itself controlled by a controlling container object 4 10. Active control objects 411 to 417, 
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for calling the operational objects (41 1), are contained within the container object 410. A single 
passthrough object, which in this example is an independent program 43 1 , is created. Each of 
the HTML pages 406 to 408 includes a page embedded control object, a singular object that has 
also been referred to as an embedded control object (container agent). An initiating object 
within a page calls the passthrough object 43 1 and passes to the passthrough object output 
information detailing a desired call to a specified operational object 441. 

The passthrough object 431 interprets the output information received from the 
embedded object 423 to generate a communication to a contained object 417, via the decoder 
(page agent) 424 so as to call the desired operational object 441. The passthrough object 43 1 
receives event data from a called operational object and returns input data to the initiating 
embedded object 423 indicative of the returned event. 

Operations performed by the page embedded controls 423 (container agents) are 
detailed in Figure 5. At step 501 an instruction is received to the effect that a call is to be made 
to the passthrough and at step 502 a question is asked as to whether the passthrough already 
exists. If this question is answered in the negative, to the effect that no pass-through has 
presently been instantiated, a passthrough is created at step 503. Alternatively, if the 
passthrough program is already under execution as a separate process, the question asked at step 
502 is answered in the affirmative and control is directed to step 504. Thus, it should be 
appreciated that these procedures ensure that it is only possible to have one passthrough 
program under execution. 

At step 504 the encoder function 434 is called which will then ultimately result in the 
object of interest being called. This in turn may result in an event being returned back. 
Consequendy, the container agent 423 includes procedures for acting upon a returning event. 

Procedures performed by the encoder function 434 are detailed in Figure 6. At step 601 
a function call is received from a page embedded object control 423, i.e. from a container agent. 
At step 602, details of the call are encoded into a message, whereafter at step 603 a method call 
is made to decoder 424, i.e. the page agent resident within the container. 
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Within the container, an appropriate call will be reconstituted in order to call a channel 
application object and the event returned to decoder 424 whereupon this is again encoded into a 
method call. 

At step 604 the method call, that is an encoded version of the event, is received and at 
step 605 the originating page is identified. 

At step 606 a question is asked as to whether the page has been registered by 
interrogating page register 435 and if this question is answered in the negative, control is 
directed to step 607, whereupon the event is buffered in event buffer 433. 

When a page is re-established, it then becomes possible for the question asked at step 
606 to be answered in the affirmative resulting in control being directed to step 608. At step 
608 the event is decoded and returned as such at step 609 to the originating page. 

Referring to Figure 3, after a transaction type has been selected at step 304, steps 30b to 
308 relate to the actual cash withdrawal process. An amount is specified by a user and in 
response to this amount being specified a slip is produced and cash is dispensed. Within the 
environment shown in Figure 4, this dispensing of cash process is performed under the control 
of channel application object 441 . The procedures involved in order to call this object are 
summarized in Figure 7. 

Initially, a user is presented with an HTML page requesting information concerning the 
transaction amount, as identified at 305 at Figure 3. The script within HTML page 406 is 
designed to implement the procedures shown in Figure 3 by making a call to the withdrawal 
transaction object 441. This consists of a first call 701 taking the form: 
SET PROPERTY ("WDL'\ "AMOUNT", "100") 

This is then followed by a call 702 to execute the method, taking the form: 
EXECUTE METHOD ("WDL", "EXECUTE") 

After completing the withdrawal transaction, an event 703 is returned to the HTML 
page 406 to the effect that the execution has completed. 
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Call 701 made by the HTML page 406 is directed towards its embedded object 423. 
The embedded object 423 makes a method call 704 to the passthrough 43 1 which encodes this 
call for transmission 705 to the decoder (page agent) 424. A conventional call 706 is then made 
by the decoder 424 to the appropriate Active X control 417. Active X control 417 then 
5 establishes a call 707 to the application object 441 . 

A similar progression is made from the HTML page 406 in order to execute the method. 
Thus, the instruction to execute is communicated at 708 from the container object 423 
embedded within the page to the passthrough object 431. Method call 709 is the made from the 
passthrough object 431 to the decoder page agent 424 that in turn makes a call 710 to the Active 
^10 X control 417 that in turn makes a call 7 1 1 to the application object 44 1 . 

When the application object 441 generates an execution complete event, this is 
submitted as event 712 to the Active X control 417 present in the container. This event is then 
submitted at 713 to the decoder page agent 424 that in turn generates a method call 714 to the 
passthrough 431. At the passthrough encoder 434, the event is reconstituted and submitted at 
15 7 15 to the page embedded control object 423. This is then conveyed at 703 to the HTML page. 

The present invention allows a process to be defined by a plurality of pages defined in a 
mark-up language such that they may be executed by a browser. The pages have executable 
scripts including Active X controls. The browser is contained within a container and Active X 
controls to external applications are placed in this container in preference to being placed in the 
20 HTML pages themselves. In this way, it is possible for these controls to be initialized upon 
start-up in preference to being initialized each time an HTML page is instantiated, 

A single passthrough is established that keeps track of the actual pages that are in 
existence. In addition, when events are returned, these events are only conveyed back to an 
initiating page if the page is still in existence and is therefore recorded as such in the register. If 
25 such a record does not exist, the event is buffered until the page is re-established. In this way, 
events are not lost if an initiating page is closed down and then re-established later. The 
passthrough therefore provides a means of communicating between the HTML pages and 
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controls existing within a container or a browser control. Furthermore, the nature of the 
passthrough ensures that events are not lost, thereby enhancing the availability of procedures 
that may be deployed by a developer because the passthrough program will ensure that events 
are not lost when new pages are loaded. Furthermore, the overhead of loading pages is 
significantly reduced in terms of their time of loading whereas their functionality is significantly 
enhanced by initializing object controls upon start-up in preference to the controls being 
established within the pages themselves. 



